1. Field of the Invention
This invention relates to a method and apparatus for modeling events.
2. Background Art
A company that sells subscriptions to customers stores information about its customers in a database. The company would like to be able to remind a customer when the customer""s subscription is about to end, and to give special offers to certain customers depending on who the customers are and how early or late the customers renew a subscription. Current database systems do not operate efficiently when the database becomes large. Current databases also lack the flexibility to be changed to allow the addition of new types of data to a customer database entry. Problems with existing database systems can be understood by first reviewing database systems.
When data is collected and stored on a computer in an organized manner that collection of data is called a database. In an effort to make the data stored in databases easily retrievable, databases are organized according to a predetermined structure. Unfortunately, once the underlying structure of the database is implemented the process of changing it is cumbersome. To add new relationships to a database the structure of the entire database must often be redefined. As a result, current database models inherently lack flexibility.
Databases are organized according to a data model that specifies the organizational structure of the database. A variety of different data models exist and each organizes data in a different manner. Examples of data models include the relational model, the object oriented model and the physical data model.
Once a data model is chosen the overall design of the database is implemented using that model. This overall design of the database is often referred to as the database schema and is defined by using a special language called a data definition language (DDL).
A database may contain one or more tables that are defined in a file called the data dictionary. Tables help keep the data in the database organized. FIG. 1 illustrates a table 100 that contains information about customers. Each table is designed to store a collection of data and is comprised of a number of rows 101-107. A row is separated into one or more columns 120-124 and each column is designated to receive values that have an associated name 140. When data is placed into the table 100 it is placed in the appropriate column 120-124. For example, values 130-135 represent a series of customer identification numbers. These values are placed in column 120. Once an entry in a column contains an item of data it is referred to as a record. Each table may hold numerous records. When a row 101-107 is filled with data it represents a unique set of records. For example, if data were placed in columns 120-124 of row 101 that data is representative of the customer that has the customer identification number 130.
A disadvantage of the way database tables are organized is that its organizational schema is predetermined and fixed. As a result current databases lack a flexible structure. For example, if a person using table 100 wanted to begin collecting other kinds of addressing information about a customer, such as the customers"" work address or electronic mail address, a new column 206 to hold that information is required and must be defined. To define a new column a new table 200 that has an additional column 206 is created. Thus an inherent disadvantage of current database systems is that the user is locked into collecting the kind of information the table is pre-defined to hold. Table 100, for example, can only hold information pertaining to a customer""s identification number, a customer""s name, a customer""s address, a customer""s phone number, and a customer""s fax number. To enter any other kind of information in Table 100 a new column must be defined.
Another disadvantage of current database systems is that every field in a table is assigned a value even if one does not exist. Referring now to Table 200 in FIG. 1, if data is entered into one of the columns in row 102 data must also entered into all the remaining columns. When no real information exists to input into a column, some other value, such as a NULL value, zero, or some other value. For example, if the value xe2x80x9cBobxe2x80x9d is placed in the column 121 of row 102 and the value xe2x80x9c14 Main Stxe2x80x9d is placed in column 122 of row 102 the remaining columns in row 102 are assigned NULL values. Since values are assigned to every row in column 120, the remaining values of each row are filled with NULL values. This occurs regardless of whether additional information is actually entered into Table 200. Once a row is filled with one piece of data the remaining entries for that row are filled with some value. Placing values inside a table even when one is not supplied wastes memory and computing resources.
Data that is stored in the records of a table can form the basis of a relationship between another table in the database as long as the other table has a related record. Data stored in a column (or columns) of a table can form the basis for a relationship between that table and another table in the database having a related column (or columns). For example, the customer table could be related to a table the customer orders table if the customer table contains a series of records having fields with the names xe2x80x9ccustomer identificationxe2x80x9d, xe2x80x9clast namexe2x80x9d, xe2x80x9cfirst namexe2x80x9d, xe2x80x9cstreet addressxe2x80x9d, xe2x80x9ccityxe2x80x9d, xe2x80x9czip codexe2x80x9d and the customer orders table has fields with the names xe2x80x9ccustomer identificationxe2x80x9d, xe2x80x9cservice providedxe2x80x9d, and xe2x80x9cdate service rendered.xe2x80x9d Since both of these tables share a field with the name xe2x80x9ccustomer identificationxe2x80x9d, the tables are both related to the same customer. Using a relationship between columns of two tables, it is possible to join these two tables to provide a single table of information that contains instances of rows from one table combined with related rows from the other table.
Tables may be related via one-to-one, one-to-many, or many-to-one relationships. In a one-to-one relationship, one row in one table is related to a single row in a second table and vice versa. For example, a row in an employee table that contains information about an employee relates to a salaries table that contains the employee""s salary information. Since an employee is typically only earning a single salary, there is a one-to-one relationship between an employee""s employee table record and the employee""s salary table record.
In a one-to-many relationship, a row in one table may be related to many rows in a second table, but each row in the second table matches only one row in the first table. For example, a state table that contains a state identifier and a state name can be related to multiple rows in the employee table. However, a row in the employees table identifies only one state of residence, for example. Conversely, a many-to-one relationship exists where many rows in one table match only one row in a second table, but each row in the second table may match many rows in the first table.
To relate two tables, it is necessary to identify one or more columns that are common to both tables. These columns are typically referred to as keys. A primary key is a unique key within a table and uniquely identifies a row within the table. A foreign key in a second table is comprised of the column(s) containing a first table""s primary key information. For example, in the employee table, an employee identifier (employeeID) can be assigned to uniquely identify each employee. The employeeID can be used as a primary key for the employees table. The employeeID can also be used as a foreign key in the salaries table. The employees and salaries tables can be joined by the employeeID columns in each table to have information from both tables available in a single record.
Applications are developed to provide a user with the ability to facilitate access and manipulation of the data contained in a DBMS. A DBMS includes a Data Manipulation Language (DML) such as Structured Query Language (SQL). A DML provides set-oriented relational operations for manipulating data in the DBMS. However, a DML requires a precise syntax that must be used to access and manipulate DBMS data. To use a DML, a user must understand and use the DML""s syntax. Instead of requiring each user that wishes to modify a DBMS"" data to learn the DML""s syntax, applications are written that provide an interface between the user and a DBMS"" DML.
A database application typically includes a graphical user interface (GUI) that is comprised of presentation elements such as a form. A form is a self-contained presentation element with predefined areas for displaying, entering and/or changing data. The predefined areas are typically referred to as fields.
Fields in a form can be read-only (e.g., a label field). A form can also have fields in which information is displayed and the user can enter information. For example, in an operation to modify an employee""s last name, a text field can be used to display the name currently stored in the database and allow the user to overwrite the display to enter the employee""s new last name. When user submits the information, the application can retrieve the user input and update the database accordingly.
To populate the fields in a form, the application developer must associate fields in the database with fields in the form. This process is typically referred to as binding database fields with form fields. In a simple example of a form, the fields contained within the form are bound to fields in a single table.
A form can be more complicated where fields receive data from multiple tables. The application developer designing a form must be aware of the relationship(s) that exist between the tables that are to be bound to the fields in the form. If, for example, the form contains fields from tables that are related via a one-to-many relationship, the application developer must design the form the accommodate multiple rows of information. For example, a form that displays a department and its job listings (which are related via a one-to-many relationship) must be able to display the department information as well as multiple job listings for that department. The form must be designed to display the department and include multiple rows to display the job listings for the department, for example.
The relationship between the department and job listings tables is a one-to-many relationship. That is, there can be many job listings for a given department. The format of the display of information related by a one-to-many relationship is different than that used to display information related by either a many-to-one or one-to-one relationship.
For example, the employees, salaries and state tables are related to each other via many-to-one (e.g., more than one employee can reside in the same state) and one-to-one relationship (e.g., each employee has a salary). Since a row in the employees table is related to a single row in state and salaries tables, the developer can design a form with fields that display information about an employee taken from these three tables. For example, the form can contain fields to display the employee""s name, state of residence and salary.
Thus, it can be seen that the design of a form depends on the type of relationships that exist between the tables. Using existing interface design tools, the application developer has been required to have knowledge of these relationships. The application developer must be aware of the structure of a database including the tables, the columns within a table and the relationships between tables. For example, an application developer that is building a form to display output retrieved from a database must associate fields in the form with columns in the database. If the form includes columns from multiple tables, the developer must be aware of the relationships that exist between the tables which includes the type of relationship.
One way to collect information and place it into a database is by using the Internet. The Internet is a worldwide network of interconnected computers. A user accesses the Internet by using an Internet client. An Internet client is a piece of computer software that communicates with the Internet via an Internet provider. An Internet provider is an organization that provides a client (e.g., an individual or other organization) with access to the Internet (via analog telephone line or Integrated Services Digital Network line, for example).
The World Wide Web (WWW) is a portion of the Internet that transfers information using HyperText Transfer Protocol (HTTP). HyperText Transfer Protocol (HTTP) is one of the standard protocols a client uses to communicate with a server on the WWW. Other protocols such as TCP/IP and FTP are also used. A server is the computer where information is stored before it is sent to the Internet client. Servers may store any kind of data. For example a server may store a database or a series of web pages. A web pages is a document that, for example, is programmed using HyperText Markup Language (HTML). HTML is one of the languages Internet clients understand.
A user can send information to the server by using an Internet client. The server can collect this information and add it to a database. This creates a database of user information. The database of user information is a collection of data about users. The information contained in the user database is typically information provided by the user, but it can also be obtained from other sources.
In one embodiment of the invention the user provides information to the server by completing an online form. For example, the user might want to receive a free subscription to an electronic newsletter. To receive the electronic newsletter the user provides the publisher of the newsletter with an electronic mail address, a street address, and credit card information. One way of providing this information is by using a web page that contains an online form. An online form is programmed in HTML by using the FORM element. HTML includes a FORM element that provides the ability to create a web page that has a fill-in form.
An HTML document containing a FORM element permits the user to enter information and send that information to the client. The user enters the information through the use of a limited number of FORM components: checkboxes; radio boxes; pull-down lists; text windows; and menus. The information entered through the FORM components is transmitted as a single unit to a gateway program on the server. In this manner the user can send information to the server. For example, the user can send the information necessary to subscribe to the electronic newsletter. Once the server receives the information provided by the user the server stores it in a database.
In one embodiment of the invention information is obtained from the user by collecting information provided by the HTTP protocol. When a user visits a web site HTTP passes information between the server and the internet client using environment variables. In this embodiment the information contained in these environment variables is collected and then stored on the server for later use. For example, the environment variables USER_NAME, DATE_GMT, and DOCUMENT_NAME all contain useful information about the user. The variable USER_NAME contains the name of the user as it is defined in the users internet client. The variable DATE_GMT specifies the date the user visits a web page and the variable DOCUMENT_NAME provide the name of the document a user is viewing. This information provided by the HTTP protocol is stored in a database and supplemented with information obtained from other sources.
The present invention provides a method that allows a developer to add complex dependency logic to an existing database without having to modify the underlying structure of the database.
The status of records in a database change over time. The status of a record is referred to as the xe2x80x9cstatexe2x80x9d of the record. When the records status changes it is called a state transition. One embodiment of the present invention provides a way to flexibly handle state transitions by using an event model. The event model is a set of one or more items called an event. Each event in the event model has an associated event type and contains dependency logic that interrelates the events in the event model with one another.
An event provides a way to manipulate data that is not dependent upon the structure of the data it is manipulating. Each event represents a set of actions that are optionally contingent upon a condition. The actions and conditions that comprise an event are determine when the event is created. Each event may have a different set of actions and conditions. This enables an event to represent a number of different things. An event can represent anything it is defined to represent.
In one embodiment of the present invention an event metamodel is created. An event metamodel is a model of one or more event models. Thus, it is a model of a model. An event metamodel can be instantiated to represent a number of different event models and the corresponding dependencies that interrelate them. The event metamodel is used, for example, to describe a set of modeled events. This is accomplished by maintaining values that represent the type of events the event metamodel describes.
The event metamodel enables the model creator to control what happens to each and every event in the event metamodel without having to modify the underlying structure of the database. Instead of changing the structure of the database a new data type can be created in the event model. Once this new data type is created it can immediately be used. Thus, the event metamodel provides a way to add functionality to a database and immediately make that functionality available for use. All of this is done without having to create new tables or change the relationship that exists between tables.